Method and system for providing secure digital music duplication

ABSTRACT

A system and method are provided wherein digital data representing content and associated license rights may copied to a storage medium, such as a removable storage medium, whereby the serial number of the copied-to storage medium is integrated into the licensing scheme utilized to secure the digital content. As a result, the digital content is pre-authenticated and bound to the copied-to storage medium, obviating the need to access a network or other location for access to the protected content.

CROSS-REFERENCE TO RELATED APPLICATIONS

This application is a reissue of U.S. Pat. No. 6,920,565, issued Jul.19, 2005, which is (1) a continuation of co-pending U.S. patentapplication Ser. No. 09/587,509, filed Jun. 5, 2000, now abandoned,which claims priority to U.S. provisional patent application No.60/181,727, filed Feb. 2, 2000, and (2) a continuation of U.S. patentapplication Ser. No. 09/588,149, filed Jun. 5, 2000, now U.S. Pat. No.6,718,446, both filed on Jun. 5, 2000. issued Jun. 6, 2004, which claimspriority to U.S. provisional patent application No. 60/181,727, filedFeb. 2, 2000.

FIELD OF THE INVENTION

The present invention relates generally to a method and system forproviding secure digital music duplication.

BACKGROUND OF THE INVENTION

Digital Rights Management (DRM) has received a lot of attention as aresult of the ease with which digital data can be re-distributed adinfinitum without corruption. DRM systems have thus attempted toimplement methods for encrypting music and applying certain digitalrights to that piece of media with the express intent that you can notcopy it, re-distribute it, or play the file without the right from thecopyright holder to do so. For example, one system has a uniqueelectronic serial number assigned to each disk. This serial number canbe and is used as a key to secure and unlock digital music with itsassociated rights. For example, a particular digital sound file can besecured using the serial number on a portable disk for a portable diskplayer, so that the song can only be played when that disk is insertedinto the system thus preventing re-distribution of the song. One uniquechallenge, therefore, is creating thousands of disks, or more, that have“secure” music that is secured using the unique serial number on eachdisk for retail sale. This process has been designed so that you cannotcopy protected music, but a company that is part of the musicdistribution chain still needs to be able to copy with license from thecopyright owners in an attempt to distribute and/or sell secure music ona specific type of media. To a company that manufactures storage mediaand related storage devices, for example, this is relevant because thecompany could sell music that can only be played on that company'sequipment or media. This is also a relevant issue with respect to theprocess used to create secure music disks for others to market.

Storage media, and in particular re-writeable storage media, is at timesshipped from a storage media manufacturer/distributor withpre-determined data already stored thereon. For example, the data may beone or more software programs, one or more data structures, one or moredata files, and/or the like. Likewise, the re-writeable storage mediamay be a magnetic or optical in nature, and may be a tape, a disk, orthe like. Moreover, the storage media may be read-only, write-only,read-write, or the like, as appropriate.

Once the storage media is shipped with the already-stored data, though,such storage media is quite obviously out of the hands of themanufacturer/distributor, who is then powerless to prevent anyone frommaking changes to the stored data on the storage media. Accordingly, itis oftentimes useful after shipment of the storage media to determinewhether the data on the storage media has changed as compared with theoriginally shipped data. In addition, during production of the storagemedia with the data thereon based on a master version, it is useful atvarious points during the production process to confirm that the data onthe storage media has not changed as compared with the data copied fromthe master. Accordingly, a benchmark can be provided that is placed onthe storage media and that is closely tied to the master.

Tying these issues together, there are many references to secure digitalrights management, but none that specifically address the problemsassociated with the mass reproduction of authenticated secure digitalmusic. Some proposed systems refer to unauthenticated secure digitalmusic that you distribute, then for which the user later applies forand/or pays for a license file to authenticate the music file. It wouldthus be advantageous to provide a robust solution for mass reproducingauthenticated secure digital data such as music data, with licenserights already in place.

SUMMARY OF THE INVENTION

The present invention provides a system and method wherein digital datarepresenting content and associated license rights may copied to astorage medium, such as a removable storage medium, whereby the serialnumber of the copied-to storage medium is integrated into the licensingscheme utilized to secure the digital content. As a result, the digitalcontent is pre-authenticated and bound to the copied-to storage medium,obviating the need to access a network or other location for access tothe protected content.

Other features of the present invention are described below.

BRIEF DESCRIPTION OF THE DRAWINGS

The method and system for providing secure digital music duplication arefurther described with reference to the accompanying drawings in which:

FIG. 1 is a block diagram showing a particular system for producing abenchmark on storage media;

FIG. 2 is a flow chart showing steps performed during controlling ofaccess to a master computer;

FIG. 3 is a block diagram showing the structure of a master image/imagefile created;

FIG. 4 is a flow chart showing steps performed during copying of amaster to the master image/image file of FIG. 3;

FIG. 5 is a block diagram showing a data structure corresponding to themaster image/image file of FIG. 3 in an image data file;

FIG. 6 is a flow chart showing steps performed during production of aproduction copy of storage media from the image file;

FIG. 7 is a flow chart showing steps performed during a comparison checkof the production copy of storage media;

FIG. 8 is a flow chart illustrating an exemplary process whereby contentis identified and protected in accordance with the present invention;

FIG. 9 is a flow chart illustrating an exemplary process whereby anencrypted disk image is built in accordance with the present invention;and

FIG. 10 is a flow chart illustrating an exemplary process whereby theimage is copied to a target medium in accordance with the presentinvention.

DETAILED DESCRIPTION OF THE INVENTION

U.S. application Ser. No. 09/587,509 and U.S. application Ser. No.09/588,149, relate to systems and methods in which data is copied from amaster storage medium to copied-to storage media. The same techniquesrelating to master disk production and target disk copying may beapplied to the present invention. Referring to FIG. 1, in producing astorage media 10 having data thereon based on a master 12, it is to beunderstood that four basic operations take place: (1) a master 12 of thedata to be stored on the storage media is obtained from an appropriatesource and is accessed through a master computer 14 having relativelysecure master copying software thereon; (2) an image file is made fromthe contents of the master 12 by way of the master computer 14; (3) theimage file is copied to the copied-to storage media 10 by way of aproduction computer 16; and (4) the image file is compared to thecopied-to storage media 10 by way of a comparison computer 18. Eachoperation will be addressed herein, in turn.

Each computer 14, 16, 18 may be any appropriate type of computer.Typically, each such computer 14, 16, 18 would have a display, one ormore data input devices (keyboard, mouse, etc.), a processor, memory,and the like. Of course, one or more such elements may not be necessary,depending on circumstances, and therefore may be removed. Each computer14, 16, 18 should of course have an appropriate storage media drive forreading from and/or writing to a storage media 10 and/or a master 12, asmay be appropriate.

In the case of the production computer 16 and the comparison computer18, the process of inserting the storage media 10 into and removing thestorage media 10 from the respective drives (arrows 1 and 2 in FIG. 1)may be automated by use of appropriate apparatus such as for example arobotic device (not shown), especially in the case of a more thanminimal volume operation. Moreover, such apparatus may also move thestorage media 10 between the computers 16, 18 and the drives thereof, asappropriate. Any appropriate automation apparatus may be employed. Sincethe details of such automation apparatus are known to the relevantpublic, further details are not provided herein except as stated below.

As seen, each computer 14, 16, 18 may be networked together as isnecessary to share information, as will be discussed in more detailbelow. Thus, each computer 14, 16, 18 can access the information on theother computers 14, 16, 18, assuming of course that appropriate securityaccess is granted. In addition or in the alternative, information may beaccessed by each computer 14, 16, 18 from a network computer or server20. Of course, any appropriate networking and sharing arrangements maybe employed. In fact, information may even be exchanged betweencomputers by hand (i.e., by portable storage media) if appropriateand/or necessary. Moreover, two or more of the three computers 14, 16,18 may even be embodied in the form of a single computer.

Controlling Use of Master Copying Software

Preliminarily, it should be ensured that the master 12 originates from atrustworthy source, and is not created by a non-approved entity.Accordingly, the master 12 should be obtained from such trustworthysource in some manner to ensure that the data on such master 12 is infact from the trustworthy source and in a form that the trustworthysource intended, and also to ensure that the data on such master 12 isitself trustworthy and has not been tampered with. The master 12 mayoriginate from any appropriate source and have any appropriate datathereon. As but one example, the master 12 may originate from themarketing department of a manufacturer of the storage media 10, wherebythe data stored on the master 12 results from cross-promotionalarrangements with other manufacturers and/or distributors. As isexplained below, the master 12 is a storage media similar to if notidentical with the copied-to storage media 10, although the master mayalternatively be a different type. Importantly, the entity copying thedata from the master 12 by way of the master computer 14 must betrustworthy also. Then, the master computer 14 receiving the master 12for copying purposes may be tightly controlled, such master computer 14includes copying software 22 that copies the data from the master 12, aswill be explained in more detail below, and the copying software 22 istightly tied to such master computer 14. Referring now to FIG. 2, themaster computer 14 includes a hardware ID (“HWID”) or the like that isunique to the master computer 14, such HWID is obtained from the mastercomputer 14 (step 201), the copying software 22 is hard-coded with suchHWID (step 203), and such copying software 22 operates only on themaster computer 14 having such HWID. For example, if the master computerincludes a PENTIUM III processor as produced and/or marketed by INTELCorporation of Santa Clara, Calif., then the HWID may be the unique IDassociated with the PENTIUM III processor (“the PENTIUM III ID”). Ofcourse, any other appropriate identifying indicia from any particularmaster computer 14 may be employed. Any appropriate methodologies may beemployed to obtain the HWID from the master computer 14 and to hard-codesuch HWID into the copying software 22. Since such methodologies shouldbe known or apparent to the relevant public, further details thereof arenot disclosed herein.

When the master computer 14 is directed to launch the copying software22 by a user or the like, such copying software 22 may access the HWIDhard-coded therein (step 205), may access the HWID of the mastercomputer (step 207), and may compare such accessed HWID with suchhard-coded HWID (step 209). The copying software 22 may then proceedonly if the accessed and hard-coded HWIDs match (step 211).

Still referring to FIG. 2, to further enhance security, the copyingsoftware 22 may require a correct password from the user thereof. Thus,the copying software is pre-programmed with such password, prompts theuser to enter such password (step 213), and proceeds only if the correctpassword is entered (step 215). Thus, such copying software 22 operatesonly if such software 22 resides on the correct master computer 14 andonly if initiated by a user with the correct password. As a result, anon-authorized entity is severely limited in its ability to copy dataonto a storage media 10 from a master 12 in the manner to be detailedbelow.

Operation of Master Copying Software 22

Once the copying software 22 has verified that it is on the correctmaster computer 14 and is being operated by a user with the correctpassword (as detailed in connection with FIG. 2), such software 22 maythen be employed to copy the data from the master 12 for purposes ofcopying such data to a copied-to storage media 10. Such copying software22 may copy the master 12 by creating a master image 24 (FIG. 3) fromthe master 12, as will be explained in more detail below.

Presumably, the master 12 and the data thereon is in its final form andhas been created by a trustworthy entity according to a particularoperating system. As such, the data is organized on the master 12according to the particular operating system, and the master 12 includesreferencing features specified by the particular operating system forreferencing the data. Here, it is to be assumed that the operatingsystem is a disk operating system such as the MICROSOFT DISK OPERATINGSYSTEM (DOS) produced and/or marketed by MICROSOFT Corporation ofRedmond, Wash., or the like. Of course, other operating systems can beutilized.

The master 12 is of course properly inserted into an appropriate drivein the master computer 14 such that the master computer 14 can accessthe data on such master 12. Referring now to FIG. 4, the copyingsoftware 22 may create such master image 24 (FIG. 3) in the followingmanner. Preliminarily, such copying software 22 as operating on themaster computer 14 accesses the master 12 in the drive thereof, and inparticular accesses a file directory on the master 12 (step 401), suchas a DOS file allocation table (FAT). Based on such FAT, and as shouldbe appreciate, the copying software 22 can ascertain file informationsuch as what data/files are located on the master 12, where suchdata/files are located on the master 12, the size of each file, ageinformation about each file, and other file information (step 403).

Based on such file information from the FAT, the copying software 22then reads all the data on the master 12 into a single image file thatconstitutes the master image 24 (step 405). Such image file/master image24 may be stored at least preliminarily in an appropriate memory on themaster computer 14, or may be preliminarily stored elsewhere.Preferably, such image file/master image 24 contains not only all thefiles on the master 12, but each FAT from the master 12 (if there ismore than one such FAT), all partition information from the master 12,all boot information from the master 12, all directory entries from themaster 12, etc. That is, the image file/master image 24 as created fromthe master 12 contains the entirety of the information stored on themaster 12, whether such information derives from a file, a filemanagement structure, a storage media management structure, or the like.Creating such an image 24 from such master 12 is known or should beapparent to the relevant public, and therefore need not be describedherein in any detail.

As may be appreciated, then, by copying the entirety of the master 12into the single image file/master image 24, such master image 24 maythen be employed at a later time to create a copied image of the master12 on a copied-to storage media 10. Moreover, the copied image on thecopied-to storage media 10 causes the copied-to storage media 10 tobehave as if it were the master 12. Thus, if the master 12 includes diskinformation that such master is a 100 megabyte magnetic disk, thecopied-to storage media 10 will behave as if it were a 100 megabytestorage disk, even if such copied-to storage media 10 is in fact a 250megabyte storage disc, for example.

Once the master image 12 is created from the master, such master image12 is preferably manipulated to include the aforementioned benchmark.Such benchmark may comprise certain tracking and verificationinformation. Thus, each copied-to storage media 10 as copied from themaster image 24 also includes such tracking and verificationinformation/benchmark. Preferably, the tracking and verificationinformation/benchmark is tied to the master image 24/image file or aportion thereof. Accordingly, and importantly, alteration of the imagefile will cause a mis-match with regard to the tracking and verificationinformation/benchmark in such image file, as will be explained below.Likewise, and also importantly, alteration of the copied-to storagemedia 10 will also cause a mis-match with regard to the tracking andverification information/benchmark in such storage media 10 as copiedfrom such image file/master image 24.

As seen in FIG. 3, the tracking and verification information/benchmarkincludes a part identifier such as a part number or model number. As maybe appreciated, such part identifier may be assigned on a random orpredetermined basis, and can be employed to label the image file/masterimage 24 with an identifier. Such part identifier may take anyparticular form. For example, such part identifier may be a 10-digitnumber, a 20-character alphanumeric, etc. As will be appreciated, thepart identifier identifies the master image 24, but may also be employedto verify data on a copied-to storage media 10 when copied from suchmaster image 24.

Preferably, the copying software 22 obtains the part identifier from anappropriate source (step 407) and writes the obtained part identifierinto an area of the master image 24/image file (step 409) such that thepart identifier appears in an inaccessible area when the image file iscopied to the storage media 10. That is, according to the architectureof any particular disk operating system, certain physical space on acorresponding storage media is inaccessible by way of such diskoperating system, or more simply is “dead”. For example, in theaforementioned MICROSOFT DOS disk operating system, at least with regardto the IOMEGA ZIP disk and drive as produced and/or marketed by IOMEGACorporation of Roy, Utah, logical block 0 of the storage media containsboot information, logical block 32 contains the FAT, and logical blocks1-31 are expected to be blank.

Since such logical blocks 1-31 are expected to be blank, such diskoperating system provides no capability to access such logical blocks1-31, or put another way such logical blocks 1-31 on such storage mediaare inaccessible by way of such disk operating system. Althoughinaccessible by the disk operating system, an appropriate utilityapplication may of course be employed to direct the drive receiving thestorage media 10 to write information to/read information from suchotherwise inaccessible logical blocks 1-31 and perhaps other dead space.Such utility application is known or should be apparent to the relevantpublic, and therefore need not be described herein in any detail.Preferably, such utility is not normally available to the general publicsuch that the general public cannot normally access such dead space.Thus, the general public cannot normally alter or otherwise compromisedata stored in the dead space on the storage media 10.

The part identifier may be a 10-byte identifier and is written into themaster image 24 to appear in the copied-to storage media in dead spaceas such. For example, in connection with the aforementioned IOMEGA ZIPdisk, such 10-byte identifier may be written to appear in logical block1. For verification, a 1-byte byte count or the like of the 10-byteidentifier may also be written into the master image 24 to appear insuch logical block 1 (step 411). For example, the 1-byte checksum andthe 10-byte identifier may be written into the master image 24 to appearin that order in logical block 1 of the storage media 24 at thebeginning thereof. Of course, the part identifier and the verifyingchecksum may be written to appear in other areas of dead space, andother forms of verification may be employed. The copying software alsomay store the part identifier in a separate file 26 (FIG. 5) for laterreference (step 413), as will be discussed in more detail below.

The tracking and verification information/benchmark may also include anencrypted security identifier closely tied to the data in the masterimage 24/image file, such as for example an encrypted checksum of atleast a portion of the data in such master image 24/image file. Thus,alteration of such data will result in a mis-match with regard to theencrypted security identifier. The copying software 22 on the mastercomputer 14 may develop the encrypted security identifier based on theentire FAT and also based on the part identifier as such items appear inthe master image 24/image file. Notably, basing such identifier on theFAT is particularly useful since practically any alteration to the dataon the copied-to storage media 10 will result in a change in the FATthereof, thus resulting in the aforementioned mis-match. Of course, suchencrypted security identifier may be based on other elements as theyappear in the master image 24/image file.

The copying software 22 may produce the encrypted security identifier bycalculating the checksum of each byte in the FAT and in the partidentifier (step 415), and then encrypting such checksum by way of anyappropriate encrypting algorithm (step 417). Thus, if the FAT or thepart identifier changes, the encrypted checksum will no longer match, aswill be discussed in more detail below. The encrypting algorithmemployed may be a one-way or two-way encrypting algorithm, and mayproduce an encrypted value having a pre-determined length, such as 100bytes. Of course, other methods of producing an encrypted securityidentifier tied to the data in the image file may be employed.

The copying software 22 then writes the resulting 100-byte encryptedchecksum into the aforementioned dead space in the same manner as thepart identifier (step 419). For example, such 100-byte encrypted numbersecurity identifier may be written into the master image 24 to appear inlogical block 1 with the 10 byte part identifier. For additionalsecurity, the copying software 22 may also write a 1-byte byte count ofthe 100-byte encrypted checksum to appear in the logical block 1 (step421). Such 1-byte byte count is written immediately after the 10-bytepart identifier, and is immediately followed by the 100-byte encryptedchecksum. Of course, other methods of writing the encrypted checksum andrelated indicia into the dead space may be employed.

Although it should be apparent to the relevant public, it isnevertheless noted that writing information into the dead space of thecopied-to storage media 10 in actuality means writing such informationinto the corresponding master image 24/image file in an appropriatelocation thereof such that such information is appropriately copied intothe dead space when the master image 24/image file is copied to thecopied-to storage media 10. It should also be apparent but again isnevertheless noted that any software that reads from/writes to such deadspace, such as the software discussed below, must include or have accessto an appropriate utility application in order that such software can infact direct the drive receiving the copied-to storage media to readfrom/write to such dead space as appropriate. Further, it should benoted that since such information is not indexed in the FAT of themaster image 24/image file or of the copied-to storage media 10, suchinformation must be written into the dead space in a pre-determinedlocation known to each entity that is to access such information.

The encrypted checksum disclosed above is never stored anywhere otherthan in the master image 24/image file and on the copied-to storagemedia 10. Instead, such encrypted checksum is re-derived at appropriatetimes and is then compared with the stored value in the master image24/image file or on the copied-to storage media to verify that the FATand the part identifier on the copied-to storage media 10 have not beenchanged as compared with the FAT and the part identifier in the masterimage 24/image file produced by copying software 22 on the mastercomputer 14. As should be appreciated, the FAT on the copied-to storagemedia 10 will change if, for example, a file is added to or deleted fromsuch media 10, a file is altered in size, location, or date of lastaccess, or the like. To summarize, then, any significant change to thedata on the copied-to storage media 10 will result in a change to theFAT thereof and will therefore result in a mis-match with regard to theoriginally derived encrypted checksum.

As it stands, the master image 24/image file produced by the copyingsoftware 22 on the master computer 14 includes the entirety of the dataon the master 12, and also includes the part identifier and theencrypted checksum stored in dead space. The copying software inaddition may calculate a second checksum of the entire master image24/image file, including the part identifier and the encrypted checksum(step 423), and then may store the second checksum in theabove-mentioned separate file 26 for later reference (step 425) toensure that the master image 24/image file has not become corrupted. Forexample, the separate file 26 is an image data file 26 that includes adata structure corresponding to the image file, where the data structureincludes an image name as given to the image file, the second checksum,and the part identifier, among other things. Of course, otherinformation may be stored in the image data file. Moreover, the imagedata file 26 may have information regarding additional image files,where each image file has a corresponding data structure with suchinformation stored therein. Alternatively, the aforementioned datastructure in the image data file may instead be stored in the masterimage 24/image file, perhaps in the dead space thereof, perhapsobviating the need for such image data file 26.

Copying the Image File to the Copied-to Storage Media

Now that a master image 24/image file based on the master 12 is presentin its finalized form, a production copy of the master 12/master image24 may be made on a copied-to storage media 10 by way of the productioncomputer 16, and specifically by production software 28 loaded onto theproduction computer 16. As should be evident, the production computer 16and production software 28 must have access to the finalized masterimage 24/image file. In addition, and as will be explained below, suchitems should also have access to the image data file 26. Such masterimage 24/image file and such image data file 26 may be located on andaccessible from the master computer 14 or the network server 20, or maybe located on and accessible to the production computer 16 itself,although such files may be located elsewhere.

The production computer 16 may be user-directed to make a productioncopy of the master image 24/image file on a copied-to storage media 10,or may automatically make such a production copy according to apre-defined routine. In either case, and referring now to FIG. 6, thecopied-to storage media 10 is appropriately mounted to an appropriatemedia drive coupled to the production computer 16 (step 601), theproduction software 28 on the production computer 16 accesses the masterimage 24/image file (step 603), and the production software 28 alsoaccesses the image data file 26 with the data structure corresponding tothe master image 24/image file, where the data structure includes theimage name as given to the master image 24/image file, the secondchecksum, and the part identifier, among other things (step 605).

After accessing the master image 24/image file and the image data file26, the production software 28 on the production computer 16 accessesthe second checksum from the corresponding data structure in the imagedata file 26 (step 607), and employs such accessed second checksum toverify that the accessed master image 24 image file is not corrupted. Inparticular, the production software 28 performs a checksum of the entireaccessed master image 24/image file including the part identifier andthe encrypted checksum to obtain a performed checksum value (step 609),and compares the performed checksum value with the accessed secondchecksum to determine whether they match (step 611). If a match isfound, the image file is not corrupted, and the production software 28may proceed (step 613). If a match is not found, the image file iscorrupted and the production software 28 does not proceed. Notably, theaforementioned checksum procedure may be performed at any appropriatetime. For example, such procedure is performed each time a master image24/image file is newly copied to the production computer 16, or eachtime the master image 24/image file is accessed to make a productioncopy on a copied-to storage media 10.

Assuming the second checksums compare favorably, the production software28 next accesses the part identifier as embedded in the dead space inthe master image 24/image file (step 615), accesses the part identifierfrom the corresponding data structure in the image data file 26 (step617), and compares the master image 24/image file part identifier withthe image data file 26 part identifier to determine whether they match(step 619). If a match is found, the image file has not beenadulterated, at least with regard to the part identifier, and theproduction software 28 may proceed (step 621). If a match is not found,the image file has been adulterated, at least with regard to the partnumber, and the production software 28 does not proceed. Suchadulteration may occur when an unauthorized entity attempts to create amaster image 24/image file without benefit of the master computer 14,whereby such unauthorized image file in fact fails to contain a properpart identifier. Of course, such adulteration may also occur under othercircumstances.

Assuming the part identifiers compare favorably, the production software28 next accesses the FAT from the master image 24/image file (step 623),performs a checksum of the FAT and the part identifier (which waspreviously accessed in step 615) (step 625), and then encrypts suchchecksum by way of the same encrypting algorithm previously employed bythe master computer 14 to produce a production computer encryptedchecksum (step 627). The production software 28 then accesses theencrypted checksum as embedded in the dead space in the master image24/image file (step 629), and compares the image file encrypted checksumwith the production computer encrypted checksum to determine whetherthey match (step 631). If a match is found, the master image 24/imagefile has not been adulterated, at least in any substantial way such thatthe FAT or the part identifier would be affected, and the productionsoftware 28 may proceed (step 633). If a match is not found, the masterimage 24/image file has been so adulterated, and the production software28 does not proceed. Again, such adulteration may occur when anunauthorized entity attempts to create a master image 24/image filewithout benefit of the master computer 14, whereby such unauthorizedmaster image 24/image file in fact fails to contain a proper encryptedchecksum. Of course, such adulteration may also occur under othercircumstances.

To summarize, then, prior to producing a producing a production copy onstorage media 10 from the master image 24/image file, the productionsoftware 28 first verifies the part identifier, which is an unencryptedvalue, and then verifies the checksum, which is an encrypted value. Ifeither verify fails, such image file is not employed to make theproduction copy. However, and of course, if both verifies succeed, suchimage file may then be appropriately employed by the production software28 on the production computer 16 to produce the production copy on themounted production (copied-to) storage media (step 635).

As should be appreciated, producing a production copy from a masterimage 24/image file as is done in step 635 is generally known to therelevant public, and therefore need not be described here in any furtherdetail. It should also be appreciated that any appropriate method forproducing such production copy from such master image 24/image file maybe employed. The production copy on the storage media 10 is identical tothe master 12 in all respects, except that such production copy has theembedded encrypted checksum and the embedded part identifier in theaforementioned dead space.

Comparing the Image File and the Copied-to Storage Media

Once the production software 28 on the production computer 16 makes theproduction copy of the master 12 on the storage media 10 from the masterimage 24/image file, such storage media 10 must be compared with themaster image 24/image file to ensure that the production copy is anaccurate rendering of the master image 24/image file. Such a compare maybe performed by comparison software 30 on the comparison computer 18(FIG. 1). As before with regard to the production computer 16, andturning now to FIG. 7, the production copy of the storage media 10 isappropriately mounted to an appropriate drive of the comparison computer18 (step 701), and the comparison software 30 on the comparison computer18 has access to the master image 24/image file and the correspondingdata structure in the image data file 26. Essentially, the comparisonsoftware 30 repeats the steps performed by the production software withregard to the second checksum, the part identifier, and the encryptedchecksum before actually performing a compare, except that suchfunctions are performed with regard to the mounted production copy ofthe storage media 10, and not the master image 24/image file.

In particular, the comparison software 30 on the comparison computer 16accesses the master image 24/image file (step 703), the comparisonsoftware 30 also accesses the image data file 26 with the data structurecorresponding to the master image 24/image file (step 705), and thesecond checksum from the corresponding data structure in the image datafile 26 (step 707), and employs such accessed second checksum to verifythat the accessed master image 24/image file is not corrupted. Inparticular, the comparison software 30 performs a checksum of the entireaccessed master image 24/image file including the part identifier andthe encrypted checksum to obtain a performed checksum value (step 709),and compares the performed checksum value with the accessed secondchecksum to determine whether they match (step 711). If a match isfound, the image file is not corrupted, and the comparison software 30may proceed (step 713). If a match is not found, the image file iscorrupted and the comparison software 30 does not proceed.

Assuming the second checksums compare favorably, the comparison software30 next accesses the part identifier as embedded in the dead space inthe production copy of the storage media 10 (step 715), accesses thepart identifier from the corresponding data structure in the image datafile 26 (step 717), and compares the master image 24/image file partidentifier with the image data file 26 part identifier to determinewhether they match (step 719). If a match is found, the data on thestorage media 10 has not been adulterated, at least with regard to thepart identifier, and the comparison software 30 may proceed (step 721).If a match is not found, the data on the storage media 10 has beenadulterated, at least with regard to the part number, and the comparisonsoftware 30 does not proceed.

Assuming the part identifiers compare favorably, the comparison software30 next accesses the FAT from the production copy of the storage media10 (step 723), performs a checksum of the FAT and the part identifier(which was previously accessed in step 715) (step 725), and thenencrypts such checksum by way of the same encrypting algorithmpreviously employed by the master computer 14 to produce a productioncomputer encrypted checksum (step 727). The comparison software 30 thenaccesses the encrypted checksum as embedded in the dead space in theproduction copy of the storage media 10 (step 729), and compares theproduction copy encrypted checksum with the comparison computerencrypted checksum to determine whether they match (step 731). If amatch is found, the data on the storage media 10 has not beenadulterated, at least in any substantial way such that the FAT or thepart identifier would be affected, and the comparison software 30 mayproceed (step 733). If a match is not found, the data on the storagemedia has been so adulterated, and the comparison software 30 does notproceed.

To summarize, then prior to comparing the production copy of the storagemedia 10 with the master image 24/image file, the comparison software 30first verifies the part identifier of the production copy, which is anunencrypted value, and then verifies the checksum of the productioncopy, which is an encrypted value. If either verify fails, suchproduction copy is deemed to be corrupted or otherwise improperly made.However, and of course, if both verifies succeed, the comparisonsoftware 30 may then compare the production copy of the storage media 10with the master image 24/image file in detail (step 735).

As should be appreciated, such detailed comparison is generally known tothe relevant public, and therefore need not be described here in anyfurther detail. It should also be appreciated that any appropriatemethod for performing such detailed comparison may be employed. Ingeneral, the detailed comparison by the comparison software 30 on thecomparison computer 18 ensures that the production copy of the storagemedia 10 is a faithful rendition of the master image 24/image file.Assuming the storage media compare succeeds, such storage media isapproved for distribution. Otherwise, the storage media is not approvedand may be discarded or may be employed for another production copy,assuming the storage media is not physically defective or otherwiseunsuitable.

It is to be noted that in performing the various steps detailed above,the copying software 22, production software 28, and comparison software30 may employ any appropriate methodologies and any appropriateprogramming, and may be written in any appropriate programming language.Since such methodologies, programming, and languages should be known orapparent to the relevant public, further details thereof are notdisclosed herein.

As should now be appreciated, benchmarks are associated with a masterimage 24/image file and are employed to ensure that such image file is afaithful representative of a master 12, and also to ensure that aproduction copy of storage media 10 made from the image file is afaithful reproduction of such image file. Thus, an intervening entitycannot manipulate the image file or the production copy without suchmanipulation being detectable. In addition, if the production copy ofthe storage media 10 is distributed and returned, the comparisonsoftware 30 on the comparison computer 18 or another computer mayperform a compare of the returned storage media 10 with thecorresponding image file to determine whether the returned storage media10 has been altered in any manner. Depending on the purpose and resultof the determination, then, appropriate action may be taken.

In the foregoing description, a new and useful benchmark is generatedthat is placed on a master image 24/image file made from a master 12 andtherefore on a production copy of a storage media 10 made from themaster image 24/image file. Accordingly, the benchmark is closely tiedto such master 12, and reference may be made to the benchmark at varioustimes to determine whether the data in the master image 24/image fileand/or on the storage media 10 has changed as compared with the master12.

Method and System for Providing Secure Digital Music Duplication

The foregoing description pertains to and enhances by way of relevantbackground the techniques of the present invention for mass reproductionof authenticated secure digital music. The present invention teachessteps for creating an encrypted image of secure Windows Media Audio(WMA) file(s), or files formatted according to a different format, thatare uniquely authenticated to a single medium, allowing a user to accessand play the files upon receipt or purchase of that medium.

These processes are described in the exemplary context of encryptioncode from Microsoft® for their particular secure WMA acm codec(compression/decompression) algorithm. However, it will be appreciatedby one of ordinary skill in the art that these processes can be usedwith any other security and codec provider in similar processes, justusing a different encryption and security method and/or algorithm.

In one embodiment of the present invention, in a first process, the usertakes unsecured WMA files that the user has encoded. Then, they areprotected using a Robodisk algorithm. This proprietary protectionoperation encrypts the files with a randomly generated key for eachfile. The Robodisk program also creates a file with the randomencryption keys used to protect the files for generating licenses storeson client machines used for duplication.

In a second process, the user builds the image from the encryptedprotected content that has not yet been authenticated to a particulardisk. The protected content is copied onto the master disk. An exactimage, referred to as an ABS image, of this master disk is then created.Audit images and checksums are created and reported for use induplication, auditing and general error control.

In a third process, the ABS image is burned or duplicated onto newtarget disk(s). After the ABS image is copied onto the disks, the disksare subjected to an integration process to authenticate the music filesto the serial number of the disk. This process uses the serial numberfrom the disk, and along with the functionality of pre-packaged codefrom Microsoft®, the integration information is created. The Robodisksoftware then integrates the content on the disk with the serial numberinformation gathered from each unique target disk. FIGS. 8 to 10illustrate in an exemplary fashion one way that these three processesmay be implemented in accordance with the present invention i.e., toprotect content, build disk images, then duplicate and integrate eachduplicated disk image. After the integration is complete, the files canbe played in a variety of portable devices and personal computersbecause the content is tied to the medium.

Using the techniques of the present invention, it is thus possible toduplicate disk images on a disk by disk basis, by protecting one disk,creating the image, copying the image, integrating the duplicatedcontent with the electronic serial number of each piece of media, andallowing it to be played on one computer. However, it is also possibleto create the image and duplicate the same image to multiple targetssimultaneously using multi-threaded code. This way, it is possible tocopy a large number of disks using only one computer, faster than anoperating system can do it sequentially, and then to integrate thecontent to authenticate it to the media onto which it was duplicated.

FIG. 8 illustrates an exemplary process by which the content isprotected with license rights. At 800, one or more audio files areencoded to an unsecured format, such as WMA, although the presentinvention is not limited to the WMA format. At 810, the encoded filesare placed into a folder or directory, and ordered accordingly if thereare multiple files. At 820, after user authentication according to anyknown user authentication technique, a proprietary Robodisk algorithmi.e., a software product that forms an image file such as an image fileaccording to the above-described techniques, is applied to the targetcontent to be protected. At 830, one or more license URLs is associatedwith the target content. This may be from a license initialization file,e.g. license.ini, or a blanket license may be chosen for the content.Alternatively, an input path may be specified for licensing information,for devices connected to a network. The digital rights contained in thelicensing schema may then be used to determine the scope of the licenserights with respect to the music or content i.e., whether rights includeunlimited play, a certain number of plays, a timed play window, etc.

At 840, the software requests that the user enter a content input path,such as the input path to the directory where content was placed at 810.At 850, the output path is selected for the content where the protectedencrypted content will be stored. At 860, the user of the software mayspecify the DRM rights level(s) for each content file to be protected.These include, but are not limited to, the application of rules relatingto device specific rendering, timing limitations, access levels and thelike. Then, at 870, the user clicks the protect button, or effects someother means of assenting to protection of the selected files with theselected license rights. As a result, at 880, the content and licenseinformation is encrypted, and stored according to the specified outputpath.

FIG. 9 illustrates an exemplary process by which an encrypted disk(master) image is created, based upon the encrypted file stored as aresult of the process of FIG. 8. After it is ensured that the computerused is selected to view hidden and system files at 900, a master diskis created at 910 by properly formatting and adding the proper volumelabel to the disk in accordance with master disk formatting procedure.This ensures that there is no residual data on the master disk that mayinterfere with the process. At 920, the protected content files createdas a result of FIG. 8 are copied to the master disk, in the order inwhich it will be desirable to render the content contained therein e.g.,for a portable device such as Hip Zip® or other type of renderingdevice. The license file is also copied to the master disk. At 930,after user authentication, using the Robodisk software, the user selectsto build an ABS image file to start the process. At 940, the user entersthe name, such as the image part number, for the ABS image file. At 950,the user selects to build the image file for all of the copied content,and at 960, the building of the image file, a secure content file, iscomplete. As mentioned previously, support for any DRM system, otherthan a system that supports WMA files, can be provided in accordancewith the present invention.

FIG. 10 illustrates an exemplary process whereby a secure content imageis burned or copied onto a target medium for mass production. At 1000,the user selects the .ABS file image name (e.g., such as created in FIG.9) and in the case of WMA files, the user ensures that the option forsupport of WMA files is selected. At 1010, the user specifies thelocation on the local machine or network location that contains the WMAprotected content. At 1020, if the same machine that protected thecontent is not being utilized, then at 1030, the user reloads the DRMlicense store, and the location of the key file is specified for diskauthentication. At 1040, the disk image is duplicated onto the targetdisk. At 1050, the content files on the disk have the appropriate DRMrights integrated with the serial number information from the targetdisk itself, thereby tying the media content to the target disk. At1060, the duplication process is completed.

FIGS. 8 to 10 illustrate an exemplary three step process whereby firstcontent is protected, then an encrypted disk image is built, and thenthe image is burned onto a target medium, tying the content to thetarget medium. Because the process is repeatable, and multiple targetmedia may be produced according to this method, the need to thereafterapply for or purchase a license is unnecessary.

As utilized herein, the term integrating refers to a variety of means ofincorporating information into a destination data file, and may refer topatching, concatenation, appending, hashing, replacing, or otherintegration techniques as well. Combinations and/or permutations of thesame may be called for during an integration process, and the means forincorporation may be driven in part by the DRM system utilized inconnection with the present invention.

The various techniques described herein may be implemented with hardwareor software or, where appropriate, with a combination of both. Thus, themethods and apparatus of the present invention, or certain aspects orportions thereof, may take the form of program code (i.e., instructions)embodied in tangible media, such as floppy diskettes, CD-ROMs, harddrives, or any other machine-readable storage medium, wherein, when theprogram code is loaded into and executed by a machine, such as acomputer, the machine becomes an apparatus for practicing the invention.In the case of program code execution on programmable computers, thecomputer will generally include a processor, a storage medium readableby the processor (including volatile and non-volatile memory and/orstorage elements), at least one input device, and at least one outputdevice. One or more programs are preferably implemented in a high levelprocedural or object oriented programming language to communicate with acomputer system. However, the program(s) can be implemented in assemblyor machine language, if desired. In any case, the language may be acompiled or interpreted language, and combined with hardwareimplementations.

The methods and apparatus of the present invention may also be embodiedin the form of program code that is transmitted over some transmissionmedium, such as over electrical wiring or cabling, through fiber optics,or via any other form of transmission, wherein, when the program code isreceived and loaded into and executed by a machine, such as an EPROM, agate array, a programmable logic device (PLD), a client computer, avideo recorder or the like, the machine becomes an apparatus forpracticing the invention. When implemented on a general-purposeprocessor, the program code combines with the processor to provide aunique apparatus that operates to perform the indexing functionality ofthe present invention. For example, the storage techniques used inconnection with the present invention may invariably be a combination ofhardware and software.

While the present invention has been described in connection withvarious embodiments described or shown in the various figures, it is tobe understood that other similar embodiments may be used ormodifications and additions may be made to the described embodiment(s)for performing the same function of the present invention withoutdeviating therefrom. For example, although in a preferred embodiment thepresent invention has been described herein with respect to the contextof music, the same concepts and techniques apply regardless of what thecontent represents. For example, the same techniques could be applied tomotion pictures, photographs, etc. Therefore, the present inventionshould not be limited to any single embodiment, but rather construed inbreadth and scope in accordance with the recitation of the appendedclaims.

1. A method for duplicating secure digital data, comprising: copyingdigital data and associated licensing data representing licensing rightsfrom a master storage medium to a plurality of target storage mediummedia; and integrating thestoring serial number information of saidonetarget storage medium into the appropriateof said plurality of targetstorage media onto a portion of said digital data and into saidlicensing datatarget storage medium after copying the associatedlicensing data from the master storage medium to said plurality oftarget storage media, whereby the content ofwherein said digital dataand thesaid license rights associated with said licensing data stored onsaid one target storage medium are self-authenticatingauthenticated bycomparing said serial number information on said one target storagemedium and a serial number of said one target storage medium.
 2. Amethod for duplicating secure digital data according to claim 1, whereinsaid licensing data is formatted according to the WMA format.
 3. Themethod for duplicating secure digital data according to claim 1, furthercomprising: selecting at least one content file for duplication, whereinsaid at least one content file is said digital data; setting digitalrights management (DRM) rights levels for each of said at least onecontent file; and generating said licensing data in accordance with saidDRM rights levels.
 4. A method for duplicating secure digital dataaccording to claim 3, wherein said selecting at least one content filefor duplication includes selecting at least one video file forduplication.
 5. A method for duplicating secure digital data accordingto claim 3, wherein said selecting at least one content file forduplication includes selecting at least one audio file for duplication.6. A method for duplicating secure digital data according to claim 3,wherein said selecting at least one content file for duplicationincludes selecting at least one software file for duplication.
 7. Amethod for duplicating secure digital data according to claim 1, furthercomprising: encrypting said at least one content file with unique keyinformation for each of said at least one content file, wherein said atleast one content file is said digital data; and storing said unique keyinformation in at least one content file and in the licensing dataassociated with said at least one content file.
 8. A method forduplicating secure digital data according to claim 1, furthercomprising: storing said digital data and said licensing data in saidmaster computer-readable medium.
 9. A computer readable non-transitorymachine-readable storage medium bearing computer executable instructionsfor carrying out the method of claim 1., the instructions comprising:instructions to copy digital data and associated licensing datarepresenting licensing rights from a master storage medium to aplurality of target storage media; and instructions to store serialnumber information of one target storage medium of said plurality oftarget storage media onto a portion of said one target storage mediumafter copying the associated licensing data from the master storagemedium to said plurality of target storage media, wherein said digitaldata and said license rights associated with said licensing data storedon said one target storage medium are authenticated by comparing saidserial number information on said one target storage medium and a serialnumber of said one target storage medium.
 10. A modulated data signalcarrying computer executable instructions for performing the method ofclaim
 1. 11. A computer system in which content on a master storagemedium may be copied to a plurality of target storage media, comprising:a computing device having read and write access to a master storagemedium and write access to a plurality of target storage medium media,wherein said computing device copies is configured to store digital dataand associated licensing data representing licensing rights from themaster storage medium to at least one of the plurality of target storagemedia, and wherein said computing device integrates the is configured tostore serial number information from said at least of one target storagemedium of the plurality of target storage media into at least one fileof said digital data and into said licensing data onto a portion of saidone target storage medium after copying the associate licensing datafrom the master storage medium to said plurality of target storagemedia, whereby the content ofwherein said digital data and the licenserights associated with said licensing data stored on said one targetstorage medium are self-authenticating authenticated by comparing saidserial number information on said one target storage medium and a serialnumber of the one target storage medium.
 12. A computer system accordingto claim 11, wherein said licensing data is formatted according to theWMA format.
 13. A computer system according to claim 11, wherein saidcomputing device selects at least one content file for duplication,wherein said at least one content file is said digital data, whereinsaid computing device receives instructions for setting DRM rightslevels for each of said at least one content file and wherein saidcomputing device generates said licensing data in accordance with saidDRM rights levels.
 14. A computer system according to claim 13, whereinsaid computing device selects at least one video file for duplication.15. A computer system according to claim 13, wherein said computingdevice selects at least one audio file for duplication.
 16. A computersystem according to claim 13, wherein said computing device selects atleast one software file for duplication.
 17. A computer system accordingto claim 11, wherein said computing device encrypts said at least onecontent file with unique key information for each of said at least onecontent file, wherein said at least one content file is said digitaldata, and said computing device stores said unique key information in atleast one content file and in the licensing data associated with said atleast one content file.
 18. A computer system according to claim 11,wherein said computing device stores said digital data and saidlicensing data in said master computer-readable medium.
 19. A method forduplicating secure digital music, comprising: selecting at least onecontent file for duplication; setting digital rights management (DRM)rights levels for each of said at least one content file; encryptingsaid at least one content file with unique key information for each ofsaid at least one content file; storing said unique key information inthe header for each of said at least one content file and in a licensefile associated with said at least one content file; storing said atleast one content file and said license file in a mastercomputer-readable medium; copying said at least one content file andsaid license file from a master computer-readable medium to a targetcomputer-readable medium; and integrating the serial number informationof said target computer-readable medium into said header of each of saidat least one content file and into said license file, whereby thecontent of said at least one content file and the license rightsassociated with said license file stored on said targetcomputer-readable medium are self-authenticating.
 20. A method forduplicating secure digital music according to claim 19, furthercomprising: copying said at least one content file and said license filefrom said master computer-readable medium to a second targetcomputer-readable medium; and integrating the serial number informationof said second target computer-readable medium into said header of eachof said at least one content file and into said license file, wherebythe content of said at least one content file and the license rightsassociated with said license file stored on said second targetcomputer-readable medium are self-authenticating.
 21. A method forduplicating secure digital music according to claim 19, wherein saidselecting at least one content file for duplication includes selectingat least one audio file for duplication.
 22. A method for duplicatingsecure digital music according to claim 19, wherein said selecting atleast one content file for duplication includes selecting at least onevideo file for duplication.
 23. A method for duplicating secure digitalmusic according to claim 19, wherein the a public key for authenticatingthe target storage medium is the serial number.
 24. A method forduplicating secure digital music according to claim 19, wherein said theunique key information is utilized as the a private key of the anasymmetric encryption algorithm utilized for encryption.
 25. A methodfor duplicating secure digital music according to claim 19, wherein saidlicense rights are formatted according to the WMA format.
 26. A computerreadable non-transitory machine-readable storage medium bearing computerexecutable instructions for carrying out the method of claim 19., theinstructions comprising: instructions to select at least one contentfile for duplication; instructions to set digital rights management(DRM) rights levels for each of said at least one content file;instructions to encrypt said at least one content file with unique keyinformation for each of said at least one content file; instructions tostore said unique key information in the header for each of said atleast one content file and in a license file associated with said atleast one content file; instructions to store said at least one contentfile and said license file in a master computer-readable medium;instructions to copy said at least one content file and said licensefile from a master computer-readable medium to a targetcomputer-readable medium; and instructions to integrate serial numberinformation of said target computer-readable medium into said header ofeach of said at least one content file and into said license file,whereby the content of said at least one content file and license rightsassociated with said license file stored on said targetcomputer-readable medium are self-authenticating.
 27. A modulated datasignal carrying computer executable instructions for performing themethod of claim
 19. 28. A method for duplicating secure digital datacomprising: copying digital data and associated data which uniquelyauthenticates said digital data from a master storage medium to aplurality of target storage media; and storing serial number informationof one target storage medium of said plurality of target storage mediaonto a portion of said target storage medium after copying theassociated data from the master storage medium to said plurality oftarget storage media, wherein said digital data and the associated datastored on said one target storage medium are authenticated by comparingsaid serial number information on said one target storage medium and aserial number of said one target storage medium.
 29. A system forduplicating secure digital data, comprising: means for copying digitaldata and associated licensing data representing licensing rights from amaster storage medium to a plurality of target storage media; and meansfor storing serial number information of one target storage medium ofsaid plurality of target storage media onto a portion of said one targetstorage medium after copying the associate licensing data from themaster storage medium to said plurality of target storage media, whereinsaid digital data and said license rights associated with said licensingdata stored on said one target storage medium are authenticated bycomparing said serial number information on said one target storagemedium and a serial number of said one target storage medium.
 30. Asystem for duplicating secure digital music, comprising: a means forselecting at least one content file for duplication; a means for settingdigital rights management (DRM) rights levels for each of said at leastone content file; a means for storing unique key information for each ofsaid at least one content file in a header for each of said at least onecontent file and in a license file associated with said at least onecontent file; a means for storing said at least one content file andsaid license file in a master computer-readable medium; a means forcopying said at least one content file and said license file from amaster computer-readable medium to a target computer-readable medium;and a means for integrating serial number information of said targetcomputer-readable medium into said header of each of said at least onecontent file and into said license file, whereby the content of said atleast one content file and license rights associated with said licensefile stored on said target computer-readable medium areself-authenticating.